-
-
Save ncoop57/955b14928b5c3a594d6d07538aff687b to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(py311) | |
~ via v3.11.10 via py311 on (us-east-1) on ☁️ nc@answer.ai(us-west1) | |
❯ vim err.log | |
INFO: 172.17.0.1:46738 - "GET / HTTP/1.1" 200 OK | |
INFO: 172.17.0.1:46738 - "GET / HTTP/1.1" 200 OK | |
INFO: 172.17.0.1:46738 - "GET / HTTP/1.1" 200 OK | |
INFO: 172.17.0.1:46738 - "GET /server HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET / HTTP/1.1" 200 OK | |
INFO: 172.17.0.1:46738 - "GET /.vscode/sftp.json HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /server HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /.vscode/sftp.json HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /about HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /about HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /debug/default/view?panel=config HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /debug/default/view?panel=config HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /v2/_catalog HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /v2/_catalog HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /server-status HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /login.action HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /_all_dbs HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /.DS_Store HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /server-status HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /.env HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /.git/config HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /login.action HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /s/230323e2532313e29323e23323/_/%3B/META-INF/maven/com.atlassian.jira/jira-webapp-dist/pom.properties HTTP/1 | |
.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /config.json HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /_all_dbs HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /telescope/requests HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /?rest_route=/wp/v2/users/ HTTP/1.1" 200 OK | |
INFO: 172.17.0.1:46738 - "GET /.DS_Store HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /.env HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /.git/config HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /s/230323e2532313e29323e23323/_/%3B/META-INF/maven/com.atlassian.jira/jira-webapp-dist/pom.properties HTTP/1 | |
.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /config.json HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /telescope/requests HTTP/1.1" 404 Not Found | |
INFO: 172.17.0.1:46738 - "GET /?rest_route=/wp/v2/users/ HTTP/1.1" 200 OK | |
~ | |
~ | |
"err.log" [New] 36L, 2830B written | |
(py311) | |
~ via v3.11.10 via py311 on (us-east-1) on ☁️ nc@answer.ai(us-west1) took 4s | |
❯ ssage It looks like someone is attempting to probe my server as soon as it comes online However, the subdomain that I'm using is random. I c | |
reate a certificate with Let's Encrypt. Is there a way for others to know what the domain name is | |
Based on your log file, I can help explain what's happening and how your domain might be discovered: | |
1 Certificate Transparency Logs | |
• When Let's Encrypt issues a certificate, it's logged in public Certificate Transparency (CT) logs | |
• These logs are searchable through services like: | |
• https://crt.sh | |
• https://transparencyreport.google.com/https/certificates | |
2 Ways your domain could be discovered: | |
• CT log monitoring (automated scanning) | |
• DNS enumeration | |
• Reverse IP lookups if you're using shared hosting | |
• Network scanning (automated bots constantly scan IP ranges) | |
3 The traffic you're seeing is typical automated scanning: | |
GET /.git/config | |
GET /.env | |
GET /wp/v2/users/ | |
GET /.vscode/sftp.json | |
These are common vulnerability scan patterns looking for: | |
• Exposed git repositories | |
• Configuration files | |
• WordPress installations | |
• Development artifacts | |
Recommendations: | |
1 Use proper security headers | |
2 Configure your firewall (e.g., fail2ban) | |
3 Consider using a WAF (Web Application Firewall) | |
4 Ensure your application only responds to valid hostnames | |
5 Keep your software updated | |
Note: These scans are normal internet background noise and not necessarily targeted attacks. | |
(py311) | |
~ via v3.11.10 via py311 on (us-east-1) on ☁️ nc@answer.ai(us-west1) took 6s | |
❯ ssage Is there a way that I can set up my subdomains so that they're not automatically registered with Let's Encrypt | |
Yes, there are several approaches to make your subdomains more private while still using HTTPS: | |
1 Use a wildcard certificate: | |
certbot certonly --manual --preferred-challenges=dns \ | |
-d *.yourdomain.com | |
This creates one certificate for all subdomains, so individual subdomain names aren't logged separately. | |
2 Use self-signed certificates with your own CA: | |
• Create your own Certificate Authority | |
• Generate certificates locally | |
• Install your CA certificate on client devices | |
• Note: Only suitable for controlled environments, not public websites | |
3 Use DNS validation instead of HTTP validation: | |
certbot certonly --manual --preferred-challenges dns | |
This is more private as it requires DNS record changes rather than public HTTP endpoints. | |
4 Alternative approach: Use a reverse proxy | |
• Put your random subdomains behind a proxy | |
• Only get certificates for the proxy domains | |
• Route traffic internally based on headers/paths | |
Important: Remember that complete domain privacy is difficult to achieve due to: | |
• DNS resolution being public by nature | |
• Network routing requirements | |
• Modern security expectations | |
The wildcard certificate approach (#1) is usually the best balance of privacy and practicality. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment